Another way of solving this is having to different guards e.g doctors and patients.

Then you could define your channels like this which signal's the broadcaster to use both guards:

Broadcast::channel('some-doctor-patient-channel-name', function ($user, $id) {
   // determine if the channel is accessible for a given user model here
}, ['guard' => 'doctor', 'patient']);

You do unfortunetly need to define this guard configuration for every channel you have currently there is no way of doing this on a global level e.g for all channels as far as i can see from the source code.

Based on this information i do not think your suggestion is necessary needed as one could just define which guard(s) a specific channel should use instead.

See relevant code here and here

Another way of solving this is having to different guards e.g doctors and patients.

Then you could define your channels like this which signal's the broadcaster to use both guards:

Broadcast::channel('some-doctor-patient-channel-name', function ($user, $id) {
   // determine if the channel is accessible for a given user model here
}, ['guard' => 'doctor', 'patient']);

You do unfortunetly need to define this guard configuration for every channel you have currently there is no way of doing this on a global level e.g for all channels as far as i can see from the source code.

Based on this information i do not think your suggestion is necessary needed as one could just define which guard(s) a specific channel should use instead.

I already authenticate my channel using this way but that issue is happening after authentication. I debug on pusher and see that,

1. Doctor (id 1) joined to a channel chat
2. Patients (id 1) joined to the same channel

and after that, pusher/redis identify the last user joined at that channel because of their same id (Laravel sent as user_id). Broadcaster not firing member_added (pusher) event because they understand the user already on this channel (because of their same id)

Ah, i get your point now, my bad for not understanding completly what you meant.

Adding this method might be useful then, however would a sensible default value be to add the retrieved model's class name as a prefix to the model's identifier something like {guard_model_class_name}:{guard_model_identifier}. This way it should work by default when using mutiple guards?

@morloderex Thanks for your suggestion. I just added a different method with previous return value (model id). If one need to prefix model identifier with something, then he/she can change it as he/she want. Otherwise default value (model id) will be used as Laravel do it currently

For this to not be breaking we may need to ensure that the new method exists on the model before calling it. Some people may not be using the Authenticatable trait and may be implementing the getAuthIdentifier method themselves.

Please revert all those spacing changes.

Now it will use default getAuthIdentifier method as a fallback